Internet Protocol (IP) multicast is a bandwidth conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of recipients, including Corporations and private homes. Applications that take advantage of IP multicast include videoconferencing, Enterprise communications, distance learning and distribution of software, stock quotes and news, amongst others.
IP multicast delivers source traffic to multiple receivers without adding any additional burden on the source or the receivers while using the least network bandwidth of any current, competing technology. Multicast packets are replicated in the network by routers enabled with supporting multicast protocols resulting in efficient delivery of data to multiple receivers in the multicast system. While multicast is a promising technology for broadcasting multimedia content, current IP multicast implementations lack ability for per host, per channel accounting, per time-of-day, and per duration accounting.
The present invention relates to a bandwidth effective mechanism employing IP multicast technology for the delivery of continuous multimedia streams such as video and audio to a group of receivers across a data network using multicast tree(s).
The closest prior art that provides similar advantages is being implemented in Set Top Boxes (STB) for Zap Tracking of TV subscribers in a Digital TV network (see DigiSoft.tv, “Dynamic Zap-Tracking™”. In that model there is client software in the STB that connects to a network server and exports all user statistics to that server. The STB solution applies only to multicast streams terminated at the STB and not to multicast streams received at the subscriber Local Area Network (LAN).
A second approach is described in the aforementioned related U.S. patent application Ser. No. 10/732,529 entitled “Multicast Flow Accounting” by Pierrick Guingo, Jerome Cornet, Arnold Jansen and Fernando Cuervo. The inventors of the above identified application propose that all the network routers exchange information on the multicast traffic using a specific messaging protocol. Each end (egress) router collects the statistics (byte, packet counts) on the multicast flows it has subscribed to. Upon request of their parent, each intermediate router will collect the information about the topology of the multicast-tree, as well as the usage information from their children. To perform a measurement of the multicast flow network usage, the Source Router requests the statistics from its children, which in turn requests them from their own children, up to the end routers. The routers reply to their parent as soon as they have the statistics from their children. Therefore, the source router will get the full topology of the multicast tree along with the traffic statistics. The combination of topology and traffic statistics at the source enables accounting of the network usage by the multicast flow. The described scheme, however, does not provide host tracking and subscriber-based billing.
A third popular approach for fine grained measurement of the network usage is “per flow measurement” (Netflow, RTFM, IPFIX . . . ) see Multicast & Anycast Group Membership. However, no multicast-specific application has been created using this technology. One option to enable per flow, per subscriber, per time-of-day, per duration, per usage multicast accounting would be to implement some per flow measurement scheme at every single interface of every router in the aggregation network, and collect the statistics in a centralized fashion at granular time intervals. However, this is not scalable and requires far too much processing in the routers, and will not be considered as a viable solution if it were implemented.
The invention disclosed in the present application represents an improvement over the above referenced prior art. First, the STB based solution, typically implemented in the form of client-server middleware, has the following limitations which the present invention solves:                a) It does not provide a general multicast flow accounting solution for the network provider. It is specific to STB terminated services and is tailored for TV Service Provider. The present invention presents a general solution for multicast tracking and accounting e.g. Digital TV, Digital Radio, streaming news feeds.        b) Home firewalls might prevent an external server from querying the STB for it's zapping data or might be set up to prevent the STB from sending it's data, whereas the present network based zap tracking doesn't need to access the home network.        c) Scaling the STB based solution is costly. Multiple accounting servers are needed in the STB model to contact every STB in the network to collect multicast flow accounting information. There is no aggregation of information provided by the network, however the network based solution of the present invention relies on IGMP Proxies and Routers to aggregate information about all connected receivers.        d) The STB based solution does not provide a network fault diagnosis function, it is located on the STB. In other words, if a customer complains that he/she can not change the channels, or does not have access to a specific channel, a network based zap tracking database, which this invention allows for, might help determine if the problem is in the STB, the network, or the video server. Customers demand network fault diagnosis for multicast services.        e) Zap tracking is not a standard feature on all STBs. Most STBs do not have a channel choice tracking client, but a network based solution can track multicast subscription history regardless of what type of STB is used.        f) The STB solution is expensive. The Service provider needs to buy the middleware and either install it on all STBs that can execute the Zap Tracking software or replace STBs before a solution is realized.        g) The STB solution provides host authorization logic in the STB, which is sometimes hacked resulting in unauthorized access to Digital TV content. However the network based solution of the present invention is more resilient to hacking because it relies on IGMP Proxies and Routers to authorize host requests for multicast content.        
Application Ser. No. 10/732,529 addresses a different billing model from the one targeted by this invention. While the related application allows billing of senders based on network usage, the present invention allows for billing senders or subscribers based on host channel subscription, the time of subscription and the duration of subscription to each and every multicast group (channel). Application Ser. No. 10/732,529 does not provide enablers for billing receivers with access to multiple multicast channels based on time of viewing, and duration of viewing. It does NOT specify a method for tracking receivers. Application Ser. No. 10/732,529 aims at providing the source of a multicast channel with a map of the multicast delivery tree without addressing receiver multicast group subscription (Zap Tracking). Tracking receiver multicast group subscription is important because it provides the service provider with the time a particular viewer tuned into a certain channel (joined a multicast group) and the duration of the viewing for billing and authorization purposes. If tracking receiver multicast group subscription was to be incorporated in the approach of the above related application, the network overhead would be unacceptable because of the requirement to propagate tree changes through the network every time a subscriber changes channel (drops one multicast group and joins another).
The “per flow measurement” (Netflow, RTFM, IPFIX . . . ) approach is a generic network monitoring solution that is not well tailored for tracking multicast group subscription of multicast receivers in a highly-dynamic multicast tree. One option to enable per flow, per receiver, per time-of-day, per duration, per usage multicast accounting would be to implement some per flow measurement scheme at every single interface of every IGMP router and Snooping Proxy in the aggregation network, and collect the statistics in a centralized fashion at frequent time intervals. However, this is highly inefficient because of the network bandwidth required to transport the per flow statistics to the centralized server. It also requires far too much processing in the routers to be considered as a viable solution.
In this application the term IGMP router is used to describe a network node that is capable of processing IGMP requests. It may be known in the field as one of: IGMP multicast router; IGMP proxy; or IGMP snooping proxy